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Abstract 

Most of the work in planning with incomplete informa- 
tion takes a “look before you leap” perspective: Ac- 
tions must be guaranteed to have their intended effects 
before they can be executed. We argue that this ap- 
proach is impossible to follow in man}' real-world do- 
mains. The agent may not have enough information to 
ensure that an action will have a given effect in advance 
of executing it. This paper describes PUCCINI, a partial- 
order planner used to control the Internet Softbot (Et- 
zioni k Weld 1994). puccini takes a different approach 
to coping with incomplete information: “Leap before 
you look!” PUCCINI doesn’t require actions to be known 
to have the desired effects before execution. However, 
it still maintains soundness, by requiring the effects to 
be verified eventually. We discuss how this is achieved 
using a simple generalization of causal links. 

Introduction 

A boy’s appetite grows very fast, and in a few moments 
the queer, empty feeling had become hunger, and the 
hunger grew bigger and bigger, until soon he was as 
ravenous as a bear. 

Poor Pinocchio ran to the fireplace where the pot was 
boiling and stretched out his hand to take the cover off, 
but to his amazement the pot was only painted! Think 
how he felt! His long nose became at least two inches 
longer. 

He ran about the room, dug in all the boxes and draw- 
ers, and even looked under the bed in search of a piece 
of bread, hard though it might be, or a cookie, or per- 
haps a bit of fish. A bone left by a dog would have 
tasted good to him! But he found nothing. . . . 

Suddenly, he saw, among the sweepings in a corner, 
something round and white that looked very much like 
a hen’s egg. In a jiffy he pounced upon it. It was an 

egg- 

— Carlo Collodi, 1 The Adventures of Pinocchio 

Pinocchio’s search for food is evocative, in part, be- 
cause it is so familiar. Whether looking for food, a pass- 
port, or information on the Web, we have all had the 
experience of searching exhaustively for something until 
we find it. Even though any single action, such as open- 
ing a drawer or looking under the bed, is likely to result 

1 Translated from the Italian by Carol Della Chiesa 


in failure, we know that if we search long enough, we 
are likely to find what we’re looking for. Pinocchio’s at- 
tempt to lift the cover from the pot is also familiar, since 
attempts to open locked doors or copy read-protected 
files result in similar frustration of our expectations. 
What these activities have in common is some precon- 
dition that we assumed to be true, but later found to 
be false. 

We are interested in the problem of building agents 
that can solve user goals in software environments, such 
as the Unix operating system or World Wide Web, in 
which the agent has massively incomplete (but correct) 
information about the world. One such agent is the 
Internet Softbot (Etzioni k Weld 1994). Internet re- 
sources and Unix commands are represented as planner 
actions, and a planner, called PUCCINI , 2 is used to find 
some combination of these actions that together will 
achieve the user’s goal. 

It should not be surprising to anyone who has looked 
for something on the Web that agents in such environ- 
ments could spend much of their time searching for files 
or Web pages in much the way that Pinocchio searched 
for something to eat. However, most planners that 
deal with incomplete information don’t behave much 
like Pinocchio. 

Most planners, by adopting some form of knowledge 
preconditions (Moore 1985), require the agent to know, 
a priori , that an action will have some desired result. As 
we argued in (Golden & Weld 1996), and will briefly dis- 
cuss here, these knowledge preconditions are represen- 
tational handcuffs, which make action representations 
more awkward and limit the utility of our planners; our 
action language, SADL, eliminates them. In this paper, 
we show how a simple generalization of causal links al- 
lows a planner to exploit the elimination of knowledge 
preconditions, without giving up soundness. We show 
empirically that this added expressiveness does not de- 
grade planner performance. 

The remainder of the paper is organized as follows. 


2 PUCCINI stands for Planning with Universal quantifi- 
cation, Conditional effects, Causal links, and INcomplete 
Information, puccini is a partial-order planner based on 
UCPOP (Penberthy k Weld 1992). An earlier version of 
puccini was called Xll. 



First, we introduce the fundamentals of the sadl lan- 
guage and the PUCCINI planner. Then, in the next 
section, we briefly discuss the problem with knowdedge 
preconditions. Although knowledge preconditions, as 
inflexible requirements of the planner, are harmful, it 
is still necessary for the planner to gather information 
in support of planning. In the following section, w*e 
show how that is done in PUCCINI. Then we consider 
the option of assuming that certain preconditions hold, 
performing the action, and verifying the preconditions 
afterward. Finally, we evaluate the cost of this added 
flexibility. 

Back in the sadl 

puccini goals and actions are described using the lan- 
guage SADL, 3 which builds on UWL (Etzioni et al. 1992) 
and ADL (Penberthy 1993). Like UWL, SADL is designed 
to represent sensing actions and information goals. To 
distinguish sensory effects from causal effects and goals 
of information from traditional goals of satisfaction, 
SADL provides annotations for goals and effects. 

Following uwl, sadl divides effects into those that 
change the world, annotated by cause, and those that 
merely report on the state of the world, annotated by 
observe. Executing actions with observe effects as- 
signs values to runtime variables that appear in those 
effects. By using a runtime variable (syntactically iden- 
tified with a leading exclamation point, e.g. ftv) as a 
parameter to a later action (or to control contingent ex- 
ecution), information gathered by one action can affect 
the agent’s subsequent behavior. For example, ping 
twain has the effect of observe (machine. alive(twain), 
ftv ), i.e. determining whether it is true or false that the 
machine named twain is alive, and wc myf ile has the 
effect observe (word, count (my file, fword)), i.e. deter- 
mining the number of words in myf ile. The variable 
ftv , above, is the truth value of the proposition ma- 
chine. alive(twain). All literals have truth values ex- 
pressed in a three- valued logic: T, F, U (unknown), or 
represented by a variable. If a truth value is not speci- 
fied, it defaults to T. 

Goals are similarly annotated. The goal satisfy(P) 
indicates a traditional goal (as in adl): achieve P by 
whatever means possible. In the presence of incom- 
plete information, we make the further requirement 
that the agent knows that P is true, so satisfy(P) 
means that KNOW(P) must be true in the final state 
of the plan. Free variables are implicitly existentially 
quantified, and the quantifier takes the widest possible 
scope. For example, satisfy (in. dir (/, tex), T) means 
u Ensure that there’s at least one file in directory tex,” 
and satisfy(in.dir (myf ile, tex), tv) means ‘"Find out 
whether or not myf ile is in tex.” 

The initially annotation, introduced in (Golden & 
Weld 1996), is similar to satisfy, but it refers to the 
time when the goal is given to the agent, not to the time 
when the goal is achieved. initially(P, tv) means that 
by the time the agent has finished executing the plan, 

3 SADL stands for Sensory Action Description Language. 


it should know whether P was true when it started. 
initially(P) is not achievable by an action that changes 
the fluent P, since such an action only obscures the ini- 
tial value of P. However, changing P after determining 
its initial value is fine. By combining initially with 
satisfy we can express ‘‘tidiness” goals: modify P at 
will, but restore its initial value by plan’s end (Golden 
& Weld 1996; Weld k Etzioni 1994). Furthermore, we 
can express goals such as “Find the the file currently 
named paper.tex, and rename it to kr.tex,” which is 
beyond the expressive power of most planners (Golden 
& Weld 1996). 

The hands-off annotation indicates a maintenance 
goal that prohibits the agent from changing the fluent 
in question. 

Like adl, SADL also supports universal quantification 
and conditional effects. Combining these features with 
observe effects yields expressive sensor models, such 
as those shown in the next section. 

puccini overview 

PUCCINI is a partial-order planner in the same family as 
SNLP (McAllester & Rosenblitt 1991) and UCPOP (Pen- 
berthy & Weld 1992). It builds plans incrementally by 
starting with an empty plan and a goal agenda of goals 
that need to be achieved. When goals are achieved, 
they are removed from the goal agenda. When actions 
are added to the plan in support of goals, their pre- 
conditions are added to the goal agenda. This process 
continues until the goal agenda is empty or some goal 
proves impossible to achieve. When a goal has been 
“achieved” by adding an action to the plan, we must 
guard against the possibility that some other action 
added later will “clobber” the goal, forcing the planner 
to re-achieve it. To prevent this from happening, the 
planner adds a causal link (Tate 1977), which records its 
commitment to achieve a given goal by using the effect 
of a given action. If effect e of A\ is used to support 
precondition q of A 2 , we represent the corresponding 
causal link as A^A?. A\ is required to precede A 2 so 
that q will be achieved by the time it’s needed. Any 
change to the plan that would violate the causal link 
is called a threat to the link, and must be resolved by 
the planner. For example, an action At with the effect 
-iq possibly occurring between actions A\ and A 2 would 
threaten the link Ai-4A 2 . This threat might be resolved 
by adding an ordering constraint to ensure that At is 
executed before A\ or after A 2 . In addition to achieving 
goals on the goal agenda and resolving threats, PUCCINI 
must execute actions. These three procedures comprise 
the top-level puccini algorithm (Figure 1). This paper 
only focuses on a narrow aspect of the goal achieve- 
ment procedure (Figure 6). For a discussion of the 
other aspects of the algorithm, consult (Golden 1997; 
Etzioni, Golden, & Weld 1997). 

Knowledge Preconditions 

Knowledge preconditions are meant to capture the in- 
formation needed by an agent to execute an action for 
a given purpose. For example, an agent opening a safe 



puccini ((.4,0,B,C,£)' 1)1 *0 

1. If £ = 0 a£ = 0 A £ C l not threatened, return 
success. 

2. Pick one of 

(a) HandleGoal(A O, B, C, 0, V) 

(b) HandleThreats(0 f B, C , Q) 

(c) s HandleExecution(A T O, B, C , £, s) 

3. PUCCINI ((A,0,B,C y £), Q , P, a) 

Figure 1: The PUCCINI Algorithm takes as input a plan, 
a goal agenda ( Q ), a domain theory (X>), and the cur- 
rent state of the world, $, which is only partially known. 
The plan consists of a set of actions (.4), ordering rela- 
tions on A ((9), variable binding constraints (6), causal 
links ( C ) and unexecuted actions in A (£). The planner 
repeatedly fixes “flaws” in the plan (open goals, threats 
and unexecuted actions) until the plan is complete. The 
lines of the algorithm relevant to this paper are shown 
in bold. 


needs to know the combination. In (Golden & Weld 
1996), we argued that the practice of specifying knowl- 
edge preconditions for actions was too restrictive and 
should be abandoned. 

Moore (Moore 1985) identified two kinds of knowl- 
edge preconditions an agent must satisfy in order to ex- 
ecute an action in support of some proposition P : First, 
the agent must know a rigid designator ( i.e ., an unam- 
biguous, executable description) of the action. Second, 
the agent must know that executing the action will in 
fact achieve P. Subsequent work by Morgenstern (Mor- 
genstern 1987) generalized this framework to handle 
scenarios where multiple agents reasoned about each 
other’s knowledge. 

The first type of knowledge precondition doesn’t 
present any problem for us, since, in our language, all 
actions are rigid designators. dial(combination(saf e)) 
is not an admissible action, but dial (31-24-15) is. 
Lifted action schemas, e.g. dial(x), are not rigid des- 
ignators, but it is easy to produce one by substituting 
a constant for x . 

Moore’s second type of knowledge precondition pre- 
supposes that an action in a plan must provably succeed 
in achieving a desired goal. This is a standard assump- 
tion in classical planning, but is overly restrictive given 
incomplete information about the world; enforcing this 
assumption by adding knowledge preconditions to ac- 
tions is inappropriate. For example, if knowledge of the 
safe’s combination is a precondition of the dial action, 
then it becomes impossible for a planner to solve the 
goal “find out whether the combination is 31-24-15” by 
dialing that number, since before executing the dial ac- 
tion, it will need to satisfy that action’s precondition of 
finding out whether 31-24-15 is the right combination! 

Eliminating the knowledge precondition from the 
dial action also allows the unhurried agent to devise 
a plan to enumerate the possible combinations until it 


finds one that works. 4 While this may seem silly, Pinoc- 
chio was following an identical strategy in his hunt for 
food. The Internet Softbot does the same when di- 
rected to find a particular user, file or web page, whose 
location is unknown. If finger and Is (Figures 2 and 
3) included knowledge preconditions, then the actions 
would be useless for locating users and files. For ex- 
ample, Is /papers only returns information about the 
file aips.tex if aips.tex is in /papers. Yet planning 
to move aips.tex into /papers misses the point if the 
goal is to find aips.tex! 

[n a broad class of domains, which we call knowledge- 
free Markov (KFM) domains, the effects of an action 
depend only on the state of the world (and not on the 
agent’s knowledge about the world) at the time of ex- 
ecution. In such domains, actions are best encoded 
without knowledge preconditions. Simple mechanical 
and software systems are naturally encoded as KFM, 
while domains involving abstract actions are typically 
not. Such actions represent complex (albeit sketchy) 
plans in their own right, and depend on the agent’s 
knowledge to be executed successfully. 

Although knowledge preconditions are problematic, 
it is often useful for an agent to plan to obtain informa- 
tion, such as the combination of a safe, either to reduce 
search or to avoid dangerous mistakes. For example, if 
there’s an alarm on the safe, then it would be a bad idea 
to try all combinations. More importantly, it is neces- 
sary that the agent know, by the time it is finished, 
that it has achieved the goal. If we don’t maintain this 
constraint, our planner is not even sound! 

Planning to Sense 

The solution is to give the planner the information 
needed to determine when obtaining information, such 
as the combination of a safe, w r ould be useful, and then 
leave it to the planner to decide how and when to ac- 
quire that information. We do so quite simply by the 
use of conditional effects (see Figures 2 and 3). Follow- 
ing (Pednault 1986), we call the precondition of a condi- 
tional effect a secondary precondition (the precondition 
of the action itself is known as a primary precondition). 
If the agent wants to know whether a conditional ef- 
fect will occur, it needs to know whether the corre- 
sponding secondary precondition is true. However, we 
don’t require the planner to achieve the secondary pre- 
conditions before executing an action, even if it wants 
the corresponding effects to occur. In this sense, the 
secondary preconditions are descriptive , not prescrip- 
tive . The planner has the option of ensuring that these 
secondary preconditions are true before it executes the 
action, but it can also verify them after the fact. We 
consider the former case in this section. We will discuss 
the latter in the next section. 

The planner can ensure that a precondition is true 
by either observing it to be true or making it true. For 
example, suppose a softbot wants to compress the file 

4 Richard Feynman estimated that he could open a safe 
using this method in four hours (Feynman 1985). 



action finger(s) 

precond: satisfy (current. shell (csh) ) 

effect: V !p 3 //, //, !u 

when lastname(/p, :>) V 
firstname(/p, s) V 
userid (/p, s) 

observe (firstname(/p, //)) A 
observe (lastname( /p, /0 ) A 
observe (userid (/p, /«)) 

Figure 2: Unix action schema. A simplified version of 
the PUCCINI finger action to find information about a user. 
This action returns information about all users whose first 
name, last name or userid is equal to the input string s. 
Variables like /p, beginning with an exclamation point, are 
called run-time variables. The values of these variables are 
determined at run time as a result of sensing. Effects labeled 
with observe designate propositions that are sensed by the 
agent, as opposed to being affected. 

action ls(d) 

precond: satisfy (current. shell (csh) ) 

effect: V //when in.dir(//, d ) 

3 !p, fn 

observe (in.dir(//> d) ) A 
observe (pathname (//, /p)) A 
observe ( name ( //, fn) ) 

Figure 3: Unix action schema. A simplified version of 
the PUCCINI Is action (Unix Is -a) to list all files in a direc- 
tory. The relation in.dir(//, d) means file //is in directory !d, 
so this action returns information about all files in a given 
directory. 

aips . tex, and decides to do so by executing the action 
compress /papers/*, which compresses every file in 
the directory /papers. The action will only succeed if 
aips.tex is actually in directory /papers. The softbot 
could subgoal on ensuring that aips . tex is in /papers, 
either by observing that aips.tex is in /papers, using 
the action Is (see Figure 3), or by moving aips.tex 
into /papers. We use the term observational link to de- 
note links, Ai € -4A 2 , in which the effect e is an observe 
effect. 

Suppose a softbot wants to find the userid of Oren 
Etzioni, a University of Washington professor. It can 
do so using the finger command (Figure 2). finger 
takes a single argument, a string, and will only provide 
information about Oren if that string is Oren’s first 
name, last name or userid. Since the softbot doesn’t 
know Oren’s userid, that will be useless to subgoal on, 
but the softbot does know Oren’s first and last names. 
Suppose it adopts the subgoal of knowing Oren’s last 
name. This can be satisfied using the softbot’s prior 
knowledge about the world. The softbot’s prior knowl- 
edge is represented in the planner as the effects of a 
dummy “initial step,” A 0 . So the planner adds a link 
from Ao to finger, representing its commitment to use 
its knowledge of the initial state to satisfy its goal of 
knowing Oren’s last name. 

Now suppose the softbot is given the goal of find- 


ing a user with the userid map, i.e., initially (userid (p, 
map)), but it has no knowledge about any users, includ- 
ing whatever user, if any, has the userid of map. The 
softbot could plan to execute finger map, but it’s less 
obvious what to do with the secondary preconditions of 
finger. Since the softbot doesn’t know anything about 
the user in question, it can’t know that user’s first name 
or last name. It also doesn’t know what user p satisfies 
the relation userid(p, map). While we could try simply 
asserting that there’s a user whose userid is map, this 
fact is not necessarily true, and asserting it into the 
softbot’s knowledge base would introduce a number of 
complications, not the least of which is that the soft- 
bot would erroneously believe that it already knew* the 
answer to the query. 

Leap before you look 

Impasses like the one above are all too common. For- 
tunately, they have a simple solution. In the case of 
finger map, above, the softbot can just execute the 
finger; it will know afterward what user has that 
userid, since the action has the effect 

when userid(/p, s) ...observe (userid(/p, /u)). 5 

In short, the softbot will know after executing finger 
map whether the secondary precondition was true before 
executing it. Since the softbot can verify after the fact 
that the precondition was true, there’s no reason not to 
go ahead and execute the action. 

What we want is the ability to temporarily assume 
the secondary precondition is true, and to later verify 
that the assumption was valid by performing an obser- 
vation. Formally, a commitment to verify an assump- 
tion is a quadruple (A p ,p, e, A e ), where p is a precondi- 
tion of some effect of A p . p is assumed to be true, and is 
to be verified by effect e of action A e . Note that, unlike 
our discussion in the previous section, it is essential that 
the verification be done by an observation , since that 
is the only w T ay to obtain information about the past. 
Executing an action that caused the precondition to be 
true would be useless, since the precondition needs to 
have been true before the action was executed. Because 
the observation will only be valid if the condition p re- 
mains unperturbed, we must protect p over the interval 
between A p and A e . 

There is a striking similarity between these commit- 
ments to verify preconditions and observational links. 
In fact, they are identical to observational links, with 
the exception that the order of the producer and con- 
sumer is reversed! We call these commitments verifi- 
cation links , and write them as A$-A e . Because we 
want to consider supporting these preconditions by ei- 
ther prior observation or later verification, we can ac- 
complish this feat quite simply by omitting the order- 
ing constraint that would normally be placed between 
the producer and consumer. Since the only difference 
between an observation link and a verification link is 

5 This reasoning depends on the fact that every user has 
at most one userid, but the planner has access to this fact. 



in the ordering constraint, omitting the ordering con- 
straint means the planner hasn’t committed to which 
kind of link it is. Eventually, the actions will be ordered, 
either in the course of planning or prior to execution. 
Once that happens, the link will be either an observa- 
tion link or a verification link, depending on the action 
order. Relaxing the ordering constraint allows for self- 
links as well, as in the case of finger map, above. For 
example, consider the following effect of Is: 

V //when in.dir(//, d) observe (in.dir(//, d)), 

where in.dir(//, d) means that file // is in directory Id. 
We can satisfy the in. dir precondition by linking to the 
effect of the same action (see Figure 4). If the desired 
file is not in the directory, the observe effect ensures 
that the agent will know that fact after executing the 
action, 6 and the assumption will be proven false. 

One potential concern about verification links is that 
they increase the size of the search space by giving 
the planner more ordering options. In fact, this is in- 
evitable, since more plans are admissible when verifica- 
tion links are allowed. However, the number of plans 
that are solutions also increases, and, due to the least- 
commitment approach, the alternative ordering options 
may never be explicitly explored. Thus, it is possi- 
ble that using verification links would actually decrease 
the number of plans explored, at least in some cases. 
Whether more or fewer plans are explored is an empir- 
ical question, which we investigate in the next section. 



satisfy(in.dir(aips, d)) 


Figure 4: puccini adds Is /papers in support of the goal 
of finding the file aips.tex. Since this relies on the con- 
ditional effect of Is, the desired outcome will only occur 
if in.dir(aips . tex, /papers) is true when Is is executed. 
Rather than trying to achieve this precondition, PUCCINI 
adds a verification link from the effect of Is, observe 
(in.dir(//, /papers)), to this precondition. The agent will 
know after executing the Is whether the precondition was 
true. 


Bookkeeping 

While we can handle assumptions elegantly by lifting 
the ordering constraints imposed along with observa- 
tional links, that doesn’t free us from bookkeeping. The 
effects supported by assumptions are still contingent, 
and we must exercise care in what we do with them. We 
should not store them in the agent’s knowledge base or 
execute actions with primary preconditions supported 
by them until they have been verified. 

6 Actually, it is the fact that the agent observes all files 
that enables the agent to conclude that other files are not 
in the directory. See (Etzioni, Golden, & Weld 1997) for a 
discussion of how this inference works. 



(a) (b) 


Figure 5: Bookkeeping for verification links: (a) A p may 
follow' A c , but is used to verify a precondition of an effect 
of A c . This effect, in turn, satisfies a primary precondition 
of A s (solid lines indicate links). The effects of A s are un- 
defined unless the precondition is satisfied, and it won’t be 
known whether A c had the desired effect until A p has been 
executed, so an ordering constraint is added to ensure that 
A s is not executed before A p (dotted lines indicate ordering 
constraints), (b) The secondary precondition of A p itself 
is supported by an action, A p > , that may be executed later. 
Since A p t is indirectly providing support for A s , it must also 
be executed before A s . 


This bookkeeping is really quite simple. If a link 
Ap-^A C may represent a verification link, as opposed 
to an observational link (i.e., A c is not constrained to 
come after A p ) all actions A s whose primary precondi- 
tions are supported by A c are required to follow A p (see 

Figure 5(a)). If A P ~-^A C turns out to be observation link, 
no harm was done in adding the constraint A p -< A s . 
The constraint is redundant, since A s must follow A p , 
by transitivity of the ordering relation (A p -< A c -< ^4 S ). 

Furthermore, if the effect e of A p itself lias a pre- 
condition supported by a (possibly later) action A p > , 
the constraint A p > -< A s will also be added (see Fig- 
ure 5(b)). In general, we require an action A s to follow 
all other actions that provide support to one of its pri- 
mary preconditions, where an action provides support 
to a given precondition if it directly supports the pre- 
condition or if it provides support to the precondition of 
an effect that directly supports the given precondition. 
These ordering constraints are added in the Add Link 
procedure (Figure 7). 

When it comes time to execute an action, all causal 
effects whose preconditions are unknown, including as- 
sumptions, must be asserted as unknown in the agent’s 
knowledge base. Additionally, all effects whose assumed 
preconditions have been verified should be asserted as 
true (this is valid, since the link guarantees that the 
agent didn’t change the condition in the interim). 

Evaluation 

While the examples we have given in this paper show 
the benefits of a “leap before you look” approach, the 
real test is how well this approach actually works in 
a real planning domain. In fact, the evolution of the 
PUCCINI planner was driven by representational prob- 
lems w r e encountered in trying to encode Unix and 
Internet action schemas for the Softbot, and trying 
to get a planner to produce reasonable plans using 








HandleGoal(A O, B, C, G, V) 

if Q ^ 0 then pop (g, S c ) from from G and select case: 

1. If g = (Context => cond }, and Context \=cond then g is 
trivially satisfied. 

2. If g is a hands-off goal, then call AddLink^o, g, nil, 
Sc. O, B) 

3. Else nondeterministically choose 

(a) Reduce(g, G) 

(b) Instantiate a new action A neu} from such 

that Satisfies(e, g) and add it to Call 

Addlink(A„ eu ,, g, e, S c , O, B). Add precon- 
ditions of A new to G . 

(c) Choose an existing action A a id from *4, such 
that Satisfies(e, g) and Call Addlink(5 p , g, e, 
A old , O, B). 

4. Propagate context labels 

Figure 6: Procedure HandleGoal. The lines of the algo- 
rithm relevant to this paper are shown in bold. 

Addlink(5 p> goal, eff, S c , O, B) 

(goal - (Context => g)\ eff = when (p) e) 

• If g is an initially goal, add S p \oC. Otherwise, 

add S p € '^ aL S c to C. 

• Unless g is an unannotated secondary precondition 
and e is an observe effect 

1. Add S p -< S c to O 

2. If e is supported (directly or indirectly) by a po- 
tential verification link, whose producer is A p , 
add A p -< S c to O 

• Add MGU(e, g) to B . 

• Add ((Context => p), S p ) to Q 

Figure 7: Procedure Addlink. The lines of the algorithm 
relevant to this paper are shown in bold. 

these schemas. Many of these; struggles are discussed 
in (Golden & Weld 1996; Etzioni, Golden, & Weld 
1997). One of the greatest representational gains came 
from the elimination of knowledge preconditions and 
the introduction of verification links. For example, 
when knowdedge preconditions were used to encode ac- 
tions, we needed no fewer than six encodings of the 
finger action (Figure 2), and even these six were not 
enough to fully capture the functionality of the one 
finger action we have now. Needless to say, this prolif- 
eration of actions presented greater search control prob- 
lems, and the addition of more search control made the 
entire system more brittle. 

Despite these gains, there are some potential pitfalls, 
which we should be on guard for. As we mentioned ear- 
lier, verification links can increase the size of the search 
space by giving the planner more ordering options. To 
determine whether this is a problem in practice, we ran 
three versions of PUCCINI on 10 representative Softbot 
goals. These goals are described in detail in Section 


7.1.1 of (Golden 1997), but, briefly, they involve find- 
ing web pages, phone numbers and files (locally and 
via FTP) and compiling (DTgX), displaying, printing, 
compressing and changing permissions on files. For ex- 
ample, goal #5 is “Display all web pages referenced by 
hyperlinks from both Dan Weld’s homepage and Oren 
Etzioni’s homepage,” which requires finding the appro- 
priate home pages, scanning both pages to find links in 
common, and then running Netscape on each common 
link. 

Table 1 shows the statistics for solving these goals, 
using each version of PUCCINI. The three versions are 
as follows: 

• VL is the version of PUCCINI presented here, which 

supports verification links and allows the producer of 

a verification link to follow the consumer. 

• NO does not allow the producer to follow the con- 
sumer, but still allows self-links (z.e., the producer is 

the consumer). 

• ->VL disallows all verification links. 

The statistics shown include both planning CPU time 
and real time for planning and execution. The real 
time reflects the time required to actually execute the 
commands and wait for completion, and thus represents 
the time that the user is most likely to care about. In 
the experiments we report, the Softbot easily solved the 
goals, using very little domain-dependent search control 
and executing the minimal number of actions needed to 
achieve the goals. 

More importantly, we find that, for the goals that 
are solvable without verification links, the use of verifi- 
cation links has virtually no impact on the size of the 
search space. With the exception of goal 5 (for ver- 
sion -»VL) the number of plans searched does not vary 
with the planner configuration. However, the number of 
solvable goals decreases significantly when verification 
links are disabled. 

[f verification links are entirely disabled (->VL), only 
two of the goals are solvable. The reason for this is that 
the SADL encodings of actions like Is and finger are 
almost impossible to plan with if the planner doesn’t 
support self-links. Due to this limitation, the compari- 
son between VL and -»VL is not entirely fair. In order to 
more fairly judge the impact of verification links, we ran 
the same problems on XI I, the predecessor of PUCCINI. 
Since XII doesn’t support verification links, the action 
encodings for that planner don’t rely on them. Three 
of the goals, which rely on actions that were not part 
of the original XII domain theory, could not be solved 
by XII and were omitted from the test suite. 

Table 2 shows the results for the seven remaining 
goals. Since the domain theories used by PUCCINI and 
xii are different, these performance results should be 
taken with a grain of salt, but they are suggestive. Of 
these goals, 1 and 2 are impossible to solve because the 
goals require the temporal expressiveness provided by 
the initially annotation, which XII does not support. 
Goal 9 is impossible to achieve without the use of veri- 
fication links, despite the fact that the xii domain was 
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Table 2: Planner statistics for seven out of ten sam- 
ple goals, given to the XI I planner, running on a Sun 
SPARCstation 20 indicates that the goal is impos- 
sible for XII to achieve. Row and column labels are from 
Table 1 


engineered to get around their absence. This goal is 
quite simple: Produce a color printout of a document 
and report the status of the print job. However, it cuts 
to the heart of a problem that stumped the Softbot 
team since the very beginning: Print jobs are produced 
by the lpr command, but lpr tells us nothing about 
them. To find out whether the print job actually ex- 
ists and what identifier it has, we must execute lpq. 
Thus, the effect of lpr, the creation of a print job, is 
contingent on the job being sent to the print queue, a 
fact that can only be verified (by lpq) after the lpr 
has been executed. This does not present a problem if 
the planner supports verification links, but it creates a 
representational headache without them. 

Conclusions 

Past work in planning required agents to know, be- 
fore executing an action, that the action would have 
its intended effect. We have shown that this restric- 
tion can be harmful, and we have shown that a simple 
change to a causal link planner, relaxing an ordering 
constraint, gives an agent the flexibility to subgoal on 
obtaining this knowledge when doing so would be fruit- 
ful, but also allows it to assume preconditions are true 
and later verify them to be true. We have shown that 
this mechanism can be implemented without impairing 
tractability. 

Related Work 

puccini is an extension of XII (Golden, Etzioni, k Weld 
1994), which is based on the IJCPOP algorithm (Pen- 
berthy k Weld 1992). PUCCINI builds on XII by sup- 
porting a more expressive language, SADL (Golden k 
Weld 1996), and handling verification links, xii builds 
on UCPOP by dealing with information goals and ef- 
fects, interleaving planning with execution and reason- 
ing with Local Closed World knowledge (lcw) (Etzioni, 
Golden, k Weld 1997). The algorithm currently used 
for interleaving planning with execution builds on the 
approach used in ipem (Ambros-Ingerson k Steel 1988). 
Unlike IPEM, PUCCINI can represent information goals 
as distinct from satisfaction goals. IPEM makes no 
such distinction, and thus cannot plan for information 
goals. PUCCINI also has its roots in the SOCRATES plan- 


ner (Lesh 1992). Like PUCCINI, SOCRATES utilized the 
Softbot domain as its testbed and interleaved planning 
with execution. However, SOCRATES utilized knowledge 
preconditions and supported a less expressive action 
language (Etzioni et al 1992). 

We believe that our use of verification links is unique. 
However, it should be possible for a Partially Observ- 
able Markov Decision Process (POMDP) (Koenig 1992; 
Dean et al 1995), or the planner C-BURIDAN (Draper, 
Hanks, k Weld 1994), to produce plans similar to those 
produced by puccini using verification links. However, 
they accomplish this by following a generate-and-test, 
approach: considering the addition of each possible sen- 
sor and testing the plan by checking it against a proba- 
bility distribution on all possible worlds. They can also 
decide not to support the precondition of a conditional 
effect , provided the probability of that effect occurring 
anyway is sufficiently high. LIsing this approach, they 
can consider all plans that achieve the goal with a given 
probability, but the computational cost is daunting. 

Some planners represent uncertain outcomes using 
conditional effects, and can execute actions for their 
uncertain effects (Kushmerick, Hanks, k Weld 1995; 
Draper, Hanks, k Weld 1994; Pryor k Collins 1996; 
Goldman k Boddy 1994). For example, Cassan- 
dra (Pryor k Collins 1996) represents uncertain out- 
comes as conditional effects with “ : unknown' 1 precondi- 
tions, and is capable of using these actions for their un- 
certain effects. Cassandra plans to achieve the goal for 
all possible outcomes of each action, and adds sensing 
actions to determine which outcome actually occurred. 
However, since Cassandra doesn’t know what the ac- 
tual preconditions of these effects are, it cannot subgoal 
on finding out whether the preconditions were true, af- 
ter the fact. Furthermore, conditional effects without 
: unknown preconditions are treated in the usual way; 
the planner is forced to achieve the precondition if it, 
wants the effect to occur. 

puccini can represent effects that are explicitly un- 
certain, by using the U truth value (Golden k Weld 
1996), but, unlike Cassandra or C-BURIDAN, it can’t 
execute these actions for their (uncertain) effects. This 
limitation stems from the fact that PUCCINI was not de- 
signed for contingency planning. In future extensions 
of puccini, we would like to address this limitation. 

Future Work 

Whenever the planner makes a decision to verify a pre- 
condition after the fact, that introduces an uncertain 
outcome upon which the success of the plan depends. 
We refer to this as a source of contingency in the plan. 
There is always the possibility that the precondition is 
false, in which case the action won’t have the desired 
effect. For example, if the agent is looking for the file 
aips.tex, and the planner adds Is /papers into the 
plan, there’s a chance aips .tex will turn out not to be 
in /papers, in which case the plan will fail. In SADL, 
all sources of contingency stem from possibly unsatis- 
fied preconditions (a precondition may be as simple as 
an equality constraint). The approach currently taken 
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Table 1: Planner statistics for ten sample goals, running on a Sun SPARCstation 20. The results are shown for the 
PUCCINI planner in three configurations: with verification links and flexible ordering (VL), without flexible ordering 
(NO), and without any verification links (-•VL). indicates that the goal is impossible for the planner in question 
to achieve. 


to deal with contingency is to interleave planning and 
execution. However, some of the techniques used in 
PUCCINI, such as the use of context labels, are borrowed 
from contingency planning. We are in the process of in- 
tegrating these techniques more completely, to produce 
a hybrid interleaved-contingency planner. 
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